Apart from the coolness factor (software engineering is not immune to fads) there are clear reasons for HTML's dominance in GUIs today. Using HTML as a GUI abstracts the GUI into a simple declarative language, similar to how Makefiles or Module::Build Build.PL files abstract the compilation+linking process, or how YACC files abstract the parsing process. This GUI declarative language is used across clients ranging from PalmOS to Cray Unix to Linux Beowulf clusters -- possibly the widest range today of platforms running a general-purpose user application (a little wider than Perl5). The web browser is the Universal Client.
Simplicity marks the web server side with the CGI server interface. Although some data munging is done during data marshalling and unmarshalling, on almost all platforms this is invisible to server programs (the exception is extremely resource-constrained systems). The CGI server data interface can accomodate any type of data, ranging from Boolean values to multi-megabyte HDTV video files. Caching, encryption, and public-key authentication are included at no extra charge.
Worse is Better Again refers to Richard P. Gabriel's The Rise of "Worse is Better", which posits that it is better to evolve software than to a do a Big Design Up Front. Another characteristic of evolved systems only alluded to in that essay is that you don't have to understand the whole, complete system before you can do anything with it (in this, "Worse is Better" is similar to Perl). This radically lowers the barrier to entry, as those who wish to tinker with the system don't have to devote months of time studying the system before working with it. This lowered barrier to entry, coupled with the ease of HTML GUI design, is why HTML is the basis of most GUI design today. This claim follows from the fact that there are many more websites than conventional applications, where many websites have one or more GUIs (think searches and preferences).
The Right Thing tends to fail in practice due to systems complexity. IMHO, developing grand unified designs reguires holding too many details of the system in your mind at one time. Although in absolute numbers there may be more details to remember about Worse is Better systems, there are fewer details to remember at any one time. Scientific studies have shown that we can only hold around seven unrelated pieces of data in our minds at one time, so the system's complexity needs to be held at or below that point to ensure that ordinary mortals can develop with that system. If you can reduce the complexity below the magic number seven, you will increase the pool of developers by adding those developers who can only handle that complexity magic number.
The crucial point in The Rise of "Worse is Better" is that Worse is Better is better for developers because of the ease of implementation of Worse is Better. As has been said, users care about applications, not OSes or hardware. (A corollary based on my experiences with librarian and electronic CAD software is that the more vertical market the application, the more ease-of-use can be sacrificed.) Platforms with the greatest ease of development will end up with the greatest number of applications, thereby making those platforms the most attractive to users. It is not just the ease of implementation of the platform, but also the ease of implementing applications for that platform that is significant to the popularity of that platform. (Fisher's Law: The popularity of a system varies linearly with the ease of development for that system.)
Maybe the real lesson of The Rise of "Worse is Better" is not The Right Thing vs. Worse is Better, but of monolithic vs. modular systems. Once CPAN really developed (which I date to Perl5 and its module system), I became significantly more productive because I was able to use the CPAN modules rather than having to write the code contained in those CPAN modules in addition to my application-specific code. Using CPAN modules serves to reduce system complexity. I don't know whether designing The Right Thing precludes modularity in that design - I have not seen anything on that subject.
Another way to reduce systems complexity is to use a higher-powered tool to create the system. Using HTML (with HTTP and CGI) to create the GUI is an example of this, as HTML's declarative language nature means that you have to write much less GUI code. Using HTML encapsulates the GUI subsystem in the HTML, thereby increasing the system modularity.
Increased modularity beats increased functionality for practical systems. This seems to be why we see so much Unix, HTML - and Microsoft Windows - in the world today. For programming languages, that is why we see so much Perl, C, C++, Java, Python, and VB. The common factor - besides popularity - of all these OSes and languages is their support for program composition by the aggregation of component parts, especially premade parts. Forth has never seen the kind of popularity it could have (IMHO) despite how easy it was for developing component parts, because the Forth community never really pushed for standardized libraries.
Unix and HTML GUIs -- how are these both "Worse is Better"? One analogy is to think of The Right Thing systems as 24-carat diamonds - large, gorgeous, highly integrated, but difficult to design with. Worse is Better systems are 24 carats of assorted, beautiful gemstones none over 1 carat in weight. This collection of gemstones does not have any gems as large and beautiful as The Right Thing gem, but its gems can be easily combined to make a large number of beautiful objects. Unix and HTML GUIs draw their strength from their modularity - Unix and its command-line tools from the decisions to treat everything as a file and most data as lines of text, while HTML GUIs are intrinsicly modular due to their implementation in a separate, declarative language.
Increased modularity beats increased functionality for popular systems. Increased modularity means increased development ease, which means an increased amount of development. Microsoft snatched victory from the jaws of defeat by OS/2 with their policy of making it relatively cheap and easy to develop for Microsoft Windows. IBM might have won the desktop wars if it had been as cheap or cheaper to develop for OS/2 as for Windows.
The spirit - the nature - of Worse is Better systems is that of modular systems that can be extended by ordinary mortals. This is why the OS battle is now between the Unix family and Microsoft Windows, this is why we use the programming languages we do, and this is why HTML GUIs are now dominant. Maximizing the use of your system requires making your system easy to extend by ordinary mortals.
